warning的作用
哲学上说“存在即是合理”，warning的必要在于它能提示开发者潜在的问题，让我们尽快调整从而提高代码质量。
warning的干扰
另一方面，如果原有工程代码量过大，warning动则上千上万，都说互联网迭代开发基本上等于高速上换轮胎，哪还有时间去抽根烟，所以在实际开发过程中不可能有专门的时间来去除warning，而又不能完全无视warning，毕竟，warning的存在是我们优化代码提高代码健壮性和稳定性的契机。
既不能熟视无睹，也无法一蹴而就，那怎么办？虽然没法立马根除，但根据“化大为小”的原则，我们可以逐一击破。
屏蔽部分warning
Xcode工程中一般都会引用第三方工程，比如pod，如果是以源码的形式引入，则很可能随着pod的增加，warning数会剧增，而这部分warning其实我们不一定有足够的控制力，即使去修改其中的代码也要考虑到后期每次升级都需要重新再来一次，过于耗费人力。去除warning只是方法，我们的目的是提高自身代码的质量，所以可以直接屏蔽第三方pod的warning。如果某些pod是公司内部的，可以推动pod的负责人去优化。
Cocoapods提供了
inhibit_all_warnings!
的指令，可以直接屏蔽所有第三方pod的warning，同时也提供了
pod 'ReactiveCocoa', '~> 2.1', :inhibit_warnings => true
的配置项，可以屏蔽某一三方库的warning。
但在Cocoapods 1.2.1版本都无效，打开pod install后的pod工程配置，inhibit_all_warnings还是NO。
但我们可以用post_install钩子直接修改各个pod工程的配置
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['GCC_WARN_INHIBIT_ALL_WARNINGS'] = 'YES'
end
end
end
增加部分warning
同时，为了更好地发挥warning的作用，我们还可以让Xcode更好地产生warning。
其他还有很多设置
Wall
Wbad-function-cast
Wcast-align
Wconversion
Wdeclaration-after-statement
Wdeprecated-implementations
Wextra
Wfloat-equal
Wformat=2
Wformat-nonliteral
Wfour-char-constants
Wimplicit-atomic-properties
Wmissing-braces
Wmissing-declarations
Wmissing-field-initializers
Wmissing-format-attribute
Wmissing-noreturn
Wmissing-prototypes
Wnested-externs
Wnewline-eof
Wold-style-definition
Woverlength-strings
Wparentheses
Wpointer-arith
Wredundant-decls
Wreturn-type
Wsequence-point
Wshadow
Wshorten-64-to-32
Wsign-compare
Wsign-conversion
Wstrict-prototypes
Wstrict-selector-match
Wswitch
Wswitch-default
Wswitch-enum
Wundeclared-selector
Wuninitialized
Wunknown-pragmas
Wunreachable-code
Wunused-function
Wunused-label
Wunused-parameter
Wunused-value
Wunused-variable
Wwrite-strings
根据需要添加。
感兴趣的可以看看 这篇文章 。
总结
我们屏蔽了第三方pod的warning，同时增加了主工程的warning，目的都是一个：更有针对性地提升代码的健壮性和稳定性。
